敏捷軟件開發不只是使用敏捷原則和實踐操作就可以的。為了發布一款成功的軟件，給終端用戶帶來積極的幫助、解決技術難題，並且讓軟件可靠部署，要想達到這樣的目標，開發團隊必須仔細考慮敏捷驅動的編程實踐和架構標準。
更為重要的是，這點關係到技術組織的生死。這和軟件開發同樣困難，而更為困難的是在一個較長時間段內定期部署新功能和升級。自動化讓部署應用程序變得可靠和可重複，其中，開發運維團隊的持續集成和持續交付（ Devops CI/CD ），以及基礎設施即代碼（ IAC ：Infrastructure as code）的工程實踐，起到了關鍵作用。通過持續測試，開發團隊在修改代碼後得以驗證其改動是否影響了已有功能。
但是，當應用程序開發完成後，原來的開發人員就可能會轉到新的項目上，或者跳槽到其他的公司。當新開發人員加入該團隊，他們在能夠可靠高效地修改代碼前，必須先了解這個應用程序的架構，理解代碼。
而且，應用程序的開發人員通常都希望不斷開發新的應用程序。雖然一直維護老的應用程序會讓你覺得舒適和安心。但是，一直被捆綁在你原有的代碼上，這既不利於你的職業發展，也不利於組織發展。
退出現有的軟件項目，轉向新的軟件開發項目最好的方式，是讓其他開發人員能夠更容易地維護你設計的軟件架構、應用程序和代碼。敏捷團隊和開發人員必須建立和堅決施行可持續發展的軟件開發實踐。
1. 不要重複造輪子
編程規則第一條：如果不需重複編寫代碼，那就不要重複編寫！具體怎樣才能做到？
可以考慮問問是否有這樣的需求。為何這個功能很重要？誰能從中受益？更具體地說，探求那些不用編碼就能解決問題的方案。有時候，沒有方案就是最好的解決方案。
你所在組織中，是否有人已經完成了類似方案的編碼？也許，某個微服務只需要略微的功能增強，或者軟件庫只需要微小的升級？在寫新的代碼前，確保先查看一下所在組織裡是否已有類似代碼。是否有第三方的解決方案，包括能滿足最低需求的價格適宜的SaaS 工具，或者開源的方案。
你是否已經看過了開源的程序庫，比如GitHub，在其中搜索符合你所在組織需求的代碼示例和代碼片段。
2. 考慮編碼量少的方案
如果你確實需要自己編寫代碼，也許可以選擇編碼量少的平台，它們可以讓你更有效地開發，比在諸如Java、.Net、PHP 和JavaScript 的開發環境中更為有效。
編碼量少的平台包括Caspio、Quick Base、Appian、OutSystems 和Vantiq 等，它們提供的工具都只需開發者編碼少量代碼，甚至有時候根本就不用編寫任何代碼。每個平台都是專注在某一個專門領域，因此也就適用於某一個特定類別的應用程序。比如，Caspio 擅長在網頁中嵌入表格和工作流。Quick Base 具備魯棒的工作流和自動化能力。Vantiq 的事件驅動架構適合IoT 和其他實時的數據應用程序。
雖然有時開發者必須要親自編碼，但他們也應當熟練使用一種或幾種上述開發平台，並且善於在合適的場景中使用它們。
3. 測試自動化
在編寫滿足需求的代碼之餘，開發者要做的最重要的事情之一是測試代碼。測試驅動的開發實踐和自動化測試工具都很成熟了，開發團隊應該把單元測試、回歸測試、性能和安全測試納入到他們的敏捷評估中。
測試除了可以幫助驗證程序編譯和發布的正確性，還可以讓代碼變得更易於維護。測試能夠記錄和例證這些代碼會產生的行為。當新的開發人員加入團隊，無意中引入了錯誤的修改時，持續測試會暫停編譯，並給開發人員提供有意義的反饋，這可以快速解決問題。
4. 在代碼之外配置所有參數
開發人員沒有任何理由在代碼中寫死系統級設置、用戶名、密碼或者其他配置信息。我看到過一些開發人員走捷徑，在程序原型中寫死了一些信息，並把這些信息帶入到了生產環境。在當今軟件架構中，這絕不應發生。這樣的硬編碼不是技術上的疑難問題，而是一種偷懶的、不負責任的編程實踐，這會帶來嚴重的後果。如果代碼被意外獲取了，這會在終端或者權限暴露的情況下遭到安全攻擊。
更進一步講，當處理遺留代碼時，任何這樣在程序裡寫死配置和參數的做法都應當看做是需要堅決解決的技術問題。
5. 遵守命名規範，編寫代碼註釋，增強可讀性
我曾經和一位天才開發人員一起工作過，他的英語不太好，打字也不快。他會在代碼裡給對象命名為a，b 和c 這樣，給局部變量命名為zz，yy 和xx。他雖然會在軟件發布前清理這樣的命名，然後提交到代碼庫，但很少會堅持到底。
不是非得通過結對編程或者一幫人一起編程才能發現這是一個恐怖的編程實踐。
團隊應當採用命名規範，如Google 的JavaScript 風格指南和Java 風格指南，並且給代碼編寫註釋，至少在模塊級別編寫註釋，最理想的是在類級別提供註釋。另外，組織機構應當考慮使用靜態代碼分析工具，它們會給開發人員提供反饋，代碼何時需要重構以優化代碼結構和可讀性。
6. 頻繁地把代碼合入版本管理庫
如果你沒有每天或者更頻繁地合入代碼到版本管理庫，這就很容易產生衝突或者其他問題，這會影響到整個團隊。一個小小的錯誤就能夠影響敏捷開發團隊的敏捷性的承諾，或者增加額外的工作來解決代碼依賴。
團隊應當就怎樣對尚未準備進入生產環境的代碼進行合入這個問題達成一致。應對這個問題的方法包括建立功能標籤（ https://martinfowler.com/articles/feature-toggles.html）和Git 分支（https://nvie.com/posts/a-successful-git-branching-model/ ）。
7. 避免編程英雄主義和復雜性
我認識的大部分開發人員都成為了專業的軟件工程師，因為他們熱愛編程挑戰。編程是一門藝術、一門科學和工藝，優秀的開發人員尋求激發思考的編程任務和優雅的實現方式。
除非說，在以下這兩者之間有一道灰色的線，否則開發人員是不會留意到這兩者的界限的：即1）解決具有挑戰性的業務和技術任務；2）以及編程英雄主義，這會給下一屆開發人員留下難以理解和維護的代碼。
對於像我們這樣有了一些編程經歷的人來說，我們懂得Perl one-liners 和使用C++ 嵌套模板帶來的便利性。有時，我們能夠找到充足的理由使用這些方法，但是，如果新來的開發人員不理解這些技術，到那時候要修改這些代碼將更具挑戰性。有時，簡單卻並不那麼優雅的代碼實踐反而更好。
小結：在敏捷軟件開發中推動敏捷性
在scrum 和敏捷開發中蘊含的思想，包括信仰、標準、代碼審查和反思，人們已經證明了這些實踐可以幫助團隊更好地協作和成功地實現編碼。但在很長的一段時間裡證明敏捷性，開發人員必須肩負起責任感，具備良好的編程實踐，這些實踐能夠讓他們開發的代碼長期可維護和可擴展。
開發團隊必須好好檢查一下他們的編程實踐。這不僅對如今的軟件演示和發布很有好處，而且對其他人維護這些應用程序和代碼也至關重要。
作者介紹
Isaac Sacolick 是《 Driving Digital: The Leader's Guide to Business Transformation through Technology 》一書的作者，這本書涵蓋了許多工程實踐，如敏捷開發、開發運維和數據科學，這些對應用程序的成功數字化都至關重要。Sacolick 是公認的頂尖社交CIO，Social、Agile and Transformation 和CIO.com 老資歷博主，以及StarCIO 主席。
原文鏈接：
https://www.infoworld.com/article/3446439/7-key-coding-practices-for-agile-developers.html?upd=1572531597662